From 49064b31017a7b4d841a04732abb5a4fbd3a0602 Mon Sep 17 00:00:00 2001 From: "kfraser@localhost.localdomain" Date: Mon, 5 Mar 2007 10:52:54 +0000 Subject: [PATCH] xen: Make dom0 domain builder behaviour match that of domU. Signed-off-by: Keir Fraser --- xen/arch/x86/domain_build.c | 4 +--- xen/include/public/xen.h | 18 ++++++++---------- 2 files changed, 9 insertions(+), 13 deletions(-) diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c index 841f181f99..5d7941ab5d 100644 --- a/xen/arch/x86/domain_build.c +++ b/xen/arch/x86/domain_build.c @@ -374,9 +374,6 @@ int construct_dom0(struct domain *d, if ( parms.f_required[0] /* Huh? -- kraxel */ ) panic("Domain 0 requires an unsupported hypervisor feature.\n"); - /* Align load address to 4MB boundary. */ - v_start = parms.virt_base & ~((1UL<<22)-1); - /* * Why do we need this? The number of page-table frames depends on the * size of the bootstrap address space. But the size of the address space @@ -384,6 +381,7 @@ int construct_dom0(struct domain *d, * read-only). We have a pair of simultaneous equations in two unknowns, * which we solve by exhaustive search. */ + v_start = parms.virt_base; vkern_start = parms.virt_kstart; vkern_end = parms.virt_kend; vinitrd_start = round_pgup(vkern_end); diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index e7b55322c2..3b6e4a8b2b 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -473,26 +473,24 @@ typedef struct shared_info shared_info_t; #endif /* - * Start-of-day memory layout for the initial domain (DOM0): + * Start-of-day memory layout: * 1. The domain is started within contiguous virtual-memory region. - * 2. The contiguous region begins and ends on an aligned 4MB boundary. - * 3. The region start corresponds to the load address of the OS image. - * If the load address is not 4MB aligned then the address is rounded down. - * 4. This the order of bootstrap elements in the initial virtual region: + * 2. The contiguous region ends on an aligned 4MB boundary. + * 3. This the order of bootstrap elements in the initial virtual region: * a. relocated kernel image * b. initial ram disk [mod_start, mod_len] * c. list of allocated page frames [mfn_list, nr_pages] * d. start_info_t structure [register ESI (x86)] * e. bootstrap page tables [pt_base, CR3 (x86)] * f. bootstrap stack [register ESP (x86)] - * 5. Bootstrap elements are packed together, but each is 4kB-aligned. - * 6. The initial ram disk may be omitted. - * 7. The list of page frames forms a contiguous 'pseudo-physical' memory + * 4. Bootstrap elements are packed together, but each is 4kB-aligned. + * 5. The initial ram disk may be omitted. + * 6. The list of page frames forms a contiguous 'pseudo-physical' memory * layout for the domain. In particular, the bootstrap virtual-memory * region is a 1:1 mapping to the first section of the pseudo-physical map. - * 8. All bootstrap elements are mapped read-writable for the guest OS. The + * 7. All bootstrap elements are mapped read-writable for the guest OS. The * only exception is the bootstrap page table, which is mapped read-only. - * 9. There is guaranteed to be at least 512kB padding after the final + * 8. There is guaranteed to be at least 512kB padding after the final * bootstrap element. If necessary, the bootstrap virtual region is * extended by an extra 4MB to ensure this. */ -- 2.30.2